Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make room for other database engines #1139

Closed
wants to merge 4 commits into from
Closed

Make room for other database engines #1139

wants to merge 4 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Dec 4, 2023

Purpose

This PR removes the need to have a primary key defined within the database. For instance Clickhouse does not support it. So some specific code is needed. With this PR, such specific code could be removed and the same SQL queries could be used.

Also it appears that when running batches, the indexes are dropped and create again. But one index was not created as intended and included the created_at field. However with this PR, an index using the created_at field is necessary to keep good performance. So the initial index is updated (instead of updating the index in the batch method).

Context

This was initially part of #1094, and moved to another PR to avoid changing internal while integrating an experimental feature.

Changes

  • compute the user existence by count (and not by returning its id)
  • order the entries using the created_at field and not the id field
  • use an explicit JOIN clause

How to test this PR

  • Unit tests should pass

Alexandre Pion added 4 commits November 22, 2023 10:05
Rely on the "created_at" field to perform the search and ordering in
database. This requires the indexes to be updated (which was already the
case when runnin batches).
@matsduf
Copy link
Contributor

matsduf commented Dec 4, 2023

@pnax, this is for v2024.1, isn't it?

@ghost ghost added this to the v2024.1 milestone Dec 4, 2023
@ghost
Copy link
Author

ghost commented Dec 4, 2023

this is for v2024.1, isn't it?

yes

Comment on lines +514 to +516
(SELECT count(*) FROM result_entries JOIN test_results ON result_entries.hash_id = test_results.hash_id AND level = ?) AS nb_critical,
(SELECT count(*) FROM result_entries JOIN test_results ON result_entries.hash_id = test_results.hash_id AND level = ?) AS nb_error,
(SELECT count(*) FROM result_entries JOIN test_results ON result_entries.hash_id = test_results.hash_id AND level = ?) AS nb_warning,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks wrong to me but maybe it just me reading it wrong. Doesn't this joined test_results shadow the test_results in the outer select? If it is, doesn't that mean that the count includes all entries for all tests just as long as they have the right level?

@@ -81,7 +81,7 @@ sub create_schema {
) or die Zonemaster::Backend::Error::Internal->new( reason => "PostgreSQL error, could not create 'test_results' table", data => $dbh->errstr() );

$dbh->do(
'CREATE INDEX IF NOT EXISTS test_results__hash_id ON test_results (hash_id)'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we still need an index for just hash_id? E.g. for the test_progress RPCAPI method.

@ghost ghost closed this by deleting the head repository Feb 9, 2024
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants